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Alloy is a lightweight modeling formalism based on relational algebra. In prior work with Fisler, 
Giannakopoulos, Krishnamurthi, and Yoo, we have presented a tool. Alchemy, that compiles Alloy 
specifications into implementations that execute against persistent databases. The foundation of 
Alchemy is an algorithm for rewriting relational algebra formulas into code for database transactions. 
In this paper we report on recent progress in improving the robustness and efficiency of this 
transformation. 

1 Introduction 

Alloy ||5l is a popular modeling language that implements the lightweight formal methods philosophy lH. 
Its expressive power is that of first-order logic extended with transitive closure, and its syntax, based on 
relational algebra, is strongly influenced by object modeling notations. The language is accompanied by 
the Alloy Analyzer: the analyzer builds models (or "instances") for a specification using SAT-solving 
techniques. Users can employ a graphical browser to explore instances and counter-examples to claims. 

Having written an Alloy specification, the user must then write the corresponding code by hand; 
consequently there are no formal guarantees that the resulting code has any relationship to the 
specification. The Alchemy project addresses this issue. Alchemy is a tool under active development 171 
m at Worcester Polytechnic Institute and Brown University, by Kathi Fisler, Shriram Krishnamurthi, and 
the author, with our students Theo Giannakopoulos and Daniel Yoo, that compiles Alloy specifications 
into libraries of database operations. This is not a straightforward enterprise since, in contrast to Z 1 8 1 and 
B LU, where a notion of state machine is built into the language. Alloy does not have a native machine 
model. 

Alchemy opens up a new way of working with Alloy specifications: as declarative notations for 
imperative programs. In this way Alloy models support a novel kind of rule-based programming, in 
which underspecification is a central aspect of program design. 

In this note we report on recent progress in improving the process of generating imperative code for 
declarative specifications in a language like Alloy. This paper is a companion to HI, which developed 
a better semantic foundation for interpreting Alloy predicates as operations. With this better foundation 
we are able to generate code for a wider class of predicates than that treated in |7 1 and also prove a more 
robust correctness theorem relating the imperative code to the original specification. 

2 Alloy and Alchemy 

Some of the material in this expository section is taken from Q. 

I. Mackie and A. Martins Moreira (Eds.): Tenth International 
Workshop on Rule-Based Programming (RULE 2009) 
EPTCS 21, 2010, pp. 77-f89l doi: 10.4204/EPTCS.21.7. 
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2.1 An overview of Alloy 

An excellent introduction to Alloy is Daniel Jackson's book [5|. Here we start with an informal 
introduction to Alloy syntax and semantics via an example. The example is a homework submission and 
grading system, shown in Figure [T] In this system, students may submit work in pairs. The gradebook 
stores the grade for each student on each submission. Students may be added to or deleted from the 
system at any time, as they enroll in or drop the course. 

The system's data model centers around a course, which has three fields: a roster (set of students), 
submitted work (relation from enrolled students to submissions), and a gradebook. Alloy uses signatures 
to capture the sets and relations that comprise a data model. Each sig (Submission, etc.) defines a unary 
relation. The elements of these relations are called atoms; the type of each atom is its containing relation. 

Fields of signatures define additional relations. The sig for Course, for example, declares roster to be 
a relation on CoursexStudent. Similarly, the relation work is of type Course x Student x Submission, but 
with the projection on Course and Student restricted to pairs in the roster relation. The lone annotation 
on gradebook allows at most one grade per submission. 

The predicates (Enroll, etc.) capture the actions supported in the system. The predicates follow a 
standard Alloy idiom for stateful operations: each has parameters for the pre- and post-states of the 
operation (c and c', respectively), with the intended interpretation that latter reflects a change applied to 
the former. Alloy facts (such as SameGradeForPair) capture invariants on the models. This particular 
fact states that students who submit joint work get the same grade. 

An important aspect of Alloy is that everything is a relation. In particular sets are viewed as unary 
relations, and individual atoms are viewed as singleton unary relations. As a consequence the in 
operator does double-duty: it is interpreted formally as subset, but also stands in for the "element-of" 
relation, in the sense that if — intuitively — a is an atom that is an element of a set r, this is expressed in 
Alloy as a in r, since a is formally a (singleton) set. 

The Alloy semantics defines a set of models for the signatures and facts. Operators over sets and 
relations have their usual semantics: U (union), n (intersection), ( , ) (tupling), and . (joiri)Q As noted 
above, in denotes subset and is also used to encode membership. Square brackets provide a convenient 
syntactic sugar for certain joins: e2[e\] is equivalent to el.el. The following relations constitute a model 
under the Alloy semantics. 

Student = {Harry, Meg} 
Submission = {hwkl} 
Grade = {A, A-, B+, B] 
Course = {cO, ci} 

roster = ({cO, Harry), {cl, Harry), {cl,Meg)) 
work = {{cl , Harry, hwkl)} 
gradebook = {{cl , Harry, hwkl , A—)} 

A model of a predicate also associates each predicate parameter with an atom in the model such that the 
predicate body holds. The above set of relations models the Enroll predicate under bindings c = cO, c' 
= cl and sNew = Meg. A model may include tuples beyond those required to satisfy a predicate: the 
Enroll predicate does not constrain the work relation for pre-existing students, so the appearance of tuple 
{cl , Harry, hwkl) in the work relation is semantically acceptable. 

'For consistency with the presentation and analysis of the algorithms below, we use standard mathematical notation in two 
places where Alloy uses ASCII notation: U is "+" in Alloy, n is "&". 
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sig Submission {} 
sig Grade {} 
sig Student {} 

sig Course { 

roster : set Student, 

work : roster Submission, 

gradebook : work — > lone Grade } 

pred Enroll (c, c' : Course, sNew : Student) { 
c\roster = c.roster U sNew and 
c\work[sNew] = } 

pred Drop (c, c' : Course, s: Student) { 
s not in c'.roster } 

pred SubmitForPair (c, c' : Course, si, s2 : Student, 
bNew : Submission) { 

// pre-condition 

si in c.roster and s2 in c.roster and 
// update 

c\work = c.work U <sl, bNew> U <s2, bNew> and 

// frame condition 

c\ gradebook = c. gradebook } 

pred AssignGrade (c, c' : Course, s : Student, 

b : Submission, g : Grade) { 
c'. gradebook in c. gradebook U <>s, Z?, g> and 
c'. roster = c.roster } 

fact SameGradeForPair { 

all c : Course, si, s2 : Student, b : Submission \ 
b in (c.wor/:[5i] & c.work[s2]) implies 

c.gradebook[sl][b] = c.gradebook[s2][b] } 



Figure 1: Alloy specification of a gradebook. 
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The reader may want to check that the relations shown do not happen to model the predicate 
SubmitForPair, in the sense that no bindings for c,c' ,sl,s2,andbNew make the body of SubmitForPair 
true. Under c = cO and c' = cl, for example, the requirement c'.gradebook = c.gradebook fails because 
the gradebook starting from c' has one tuple while that starting from c has none. The requirement on 
work also fails. Similar inconsistencies contradict other possible bindings for c and c'. 

2.2 An overview of Alchemy 

We illustrate Alchemy in the context of the gradebook specification from Figure [T] Alchemy creates a 
database table for each relation (e.g., Submission, roster), a procedure for each predicate (e.g.. Enroll), 
and a function for creating new elements of each atomic signature (e.g., CreateSubmission). A sample 
session using Alchemy might proceed as follows. We create a course with two students using the 
following command sequence: 

cs311 = CreateCoursei" cs3^^")■, 
pete = CreateStudent{"Pe\e"); 
caitlin = CreateStudent{" Ca\\.\'\n"); 
Enroll{cs311, pete); 
Enroll{cs3Il, caitlin) 

Note that the Enroll function takes only one course-argument, in contrast to the two in the original Alloy 
predicate, since the implementation maintains only a single set of tables over time (the second course 
parameter in the predicate corresponds to the resulting updated table). Executing the Enroll function 
adds the pairs ("cs3H", "Pete") and ("cs311", "Caitlin") to the roster table. The second clause of the 
Enroll specification guarantees that the work table will not have entries for either student. 
Next, we submit a new homework for "Pete" and "Caitlin": 

hwkl = CreateSubmissioni" hwM "); 
SubmitForPair{cs31I, pete, caitlin, hwkl) 

The implementation of SubmitForPair is straightforward relative to the specification. It treats the first 
clause in the specification as a pre-condition by terminating the computation with an error if the clause 
is false in the database at the start of the function execution. Next, it adds the work tuples required in the 
second (update) clause. It ensures that the gradebook table is unchanged, as required by the third clause. 
Assigning a grade illustrates the way that Alloy facts constrain Alchemy 's updates: 

grade A = CreateGrade(" A"); 
AssignGrade{cs311, pete, hwkl, gradeA) 

AssignGrade inserts a tuple into the gradebook relation according to the first clause, and checks that 
the roster is unchanged according to the second. If execution were to stop here, however, the resulting 
tables would contradict the SameGradeForPair invariant (which requires "Caitlin" to receive the same 
grade on the joint assignment). Alchemy determines that adding the tuple {cs3 1 1 ,Caitlin,hwkl , A) 
to gradebook will satisfy both the predicate body and the SameGradeForPair fact, and executes this 
command automatically. If there is no way to update the database to respect both the predicate and the 
fact. Alchemy will raise an exception. This could happen, for example, if the first clause in AssignGrade 
used =instead of in : in this case, adding the repairing tuple would violate the predicate body). 
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Maintaining invariants Alloy's use of facts to constrain possibly-underspecified predicates offers a 
powerful lightweight modeling tool. The facts in an Alloy specification are axioms in the sense that they 
hold in any instance for the specification. We may view the facts as integrity constraints: they capture 
the fundamental invariants to be maintained across all transactions. Alchemy will guarantee preservation 
of all facts as database invariants. This is akin to the notion of repair of database transactions. 

2.3 Formalities 

Alloy specifications Formally, the Alloy specifications we treat in this paper are tuples of signatures, 
predicates, and facts. In practice Alloy specifications may also include assertions to be checked by the 
analyzer, but they do not play a direct role in Alchemy's code generation so we omit them here. 

• A signature specifies its type name and a set of fields. Each field has a name and a type specification 
Ao ^ Ai ^ . . . — > A„, where each A, is the type name of some signature. 

• A predicate has a header and a body. The header declares a set of variable names, each with an 
associated signature type name; the body is a formula in which the only free variables are defined 
in the header. 

• A fact is a closed formula, having the force of an axiom: models of a specification are required to 
satisfy these facts. Alloy permits the user to specify certain constraints on the signatures and fields 
when they are declared, such as "relation r may have at most one tuple." These can be alternatively 
expressed as facts and, for simplicity of presentation, we assume this is always done. 

The following language for expressions and formulas is essentially equivalent to the Kernel language 
of Alloy [5] (modulo the lexical differences between standard mathematical notation used here and 
Alloy's ASCII). 

expr .-.•= rel | var | none | expr binop expr | unop expr 
binop .-.•= U I n I - I . I (,) 
unop .-.•= --^1 * 

formula .-.•= elemFormula [ compFormula | quantFormula 
elemPormula .-.•= expr in expr | expr = expr 

compFormula .-.•= not formula | formula A formula | formula V formula 
quantFormula .-.•= V var: expr { formula } | 3 var: expr { formula } 

State-based specifications The elements of an Alloy specification suggest natural implementation 
counterparts. The signatures lay out relations that translate directly into persistent database schemas. The 
facts — those properties that are meant to hold of all models constructed by Alloy — function as database 
integrity constraints. Finally, under a commonly idiom, certain predicates in an Alloy specification 
connote state changes. It is these state-based specifications that Alchemy (currently) treats. 

The state-transition idiom is a commonly understood convention rather than a formal notion in Alloy. 
To precisely define the class of specifications that Alchemy treats, we first require some terminology. Fix 
a distinguished signature, which we will call State. An immutable type is one with no occurrences of the 
State signature. 

The assumptions Alchemy makes about the specifications it treats are: 

• specifications are state-based, and 

• facts have at most one variable of type State, and this variable is unprimed and 
universally quantified. 
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An operational semantics The static semantics of Alloy is based on the class of relational algebras. 
To give an operational semantics for state-based Alloy specifications, one that takes seriously the reading 
of predicates as state-transformers, we pass to the class of transition systems whose nodes are relational 
algebras. We also assume that each state has a single atom of type State. When individual relation 
algebras are read as database instances, transitions between states can be viewed as database update 
sequences transforming one state to another. We adopt a constant-domain assumption concerning our 
transition systems. Space consideration prohibit us from presenting the motivation and justification for 
this (including the explanation why it is not as great a restriction as it may appear); details are in Q. 

Since predicates have parameters, the meaning of a predicate is relative to bindings from variables 
to values. It is technically convenient to assume that for a given specification we identify, for each type, 
a universe of possible values of this type. Then an environment r] is a mapping from typed variables to 
values. 

Definition 1 (Operational semantics of predicates). Let p be a predicate with the property that p has 
among its parameters exactly two variables s and s' of type State, and let r\ be an environment. The 
meaning lp}r\ of p under r\ is the set of pairs (/,/') of instances such that 

• r\ maps the parameters of p into the set of atoms of / (which equals the set of atoms of /'), mapping 
the unprimed State parameter to the State-atom of / and the primed State parameter to the State- 
atom of /'; 

• (/,/') makes the body of p true under the environment r\: occurrences of the State variable s are 
interpreted in /, while occurrences of the State variable s' are interpreted in /'. 

The meaning of a predicate pis a. set of transitions because p can be applied to different nodes, with 
different bindings of the parameters of course, but also — and more interestingly — because predicates 
typically under-specify actions: different implementations of a predicate can yield different outcomes /' 
on the same input /. Any of these should be considered acceptable as long as the relation between pre- 
and post-states is described by the predicate. 

3 Main Result 

We observed that a predicate p determines a family of binary relations over instances, parametrized by 
environments. That is, for a given environment r\: 

lpj^ -.Instil'"''. (1) 

Now suppose ? is a procedure defining a database transaction (so t is the sort of procedure that a predicate 
p specifies). Given an instance / and an environment r\, t may return a new instance /', terminate 
with failure, or may diverge. None of the procedures we describe in this paper will diverge, so we 
are considering procedures t that (under an environment) determine a function over instances: 

pjri : Inst {Inst + fail) . (2) 

Alchemy's job is precisely the following: given predicate p, construct a procedure t = code{p) such that 
the semantics of code{p) as given in[2]refines the semantics of p as given in[Tl in the following sense. 

Theorem 2 (Main theorem). Let p be a predicate and let code(p) be any backtracking implementation 
of the algorithm Ap, given in Definition\5\below. Then for each instance I and each environment r\ 
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1. [[code(p)]ri terminates on I; 

2. If there exists any instance I' such that {I, I') satisfies p under T] then the result of [code(p)]ri is 
such an I'. In particular in this situation \co6e{p)\ does not return "failure" under r] on I. 

Proof. The proof is given in Section 14.41 □ 

It is worth noting that the task of generating updates from specification submits to an uninteresting 
trivial solution, particularly if we are willing to tolerate partial functions. Given predicate p we could 
define code{p) by: on input I, exhaustively generate all possible I'; for each one test whether {1,1') in 
IpJ. If and when such an I' is found, replace I by I'. Obviously this is a silly algorithm, even though it 
is "correct" in a formal sense. Our goal with Alchemy is to write code that is intuitively reasonable, and 
still is correct in the sense of Theorem |2] 



4 Code generation 

Suppose we are given an Alloy predicate p. Alchemy generates code for a procedure with parameters 
corresponding to those of p (without the primed parameter). 

As observed above, a crucial aspect of Alloy is that it encourages "lightweight" specifications of 
procedures: the designer is free to ignore details about the computation that she may consider inessential. 
As a consequence. Alchemy must be extremely flexible: different input instances may require quite 
different computations in order to satisfy a specification, yet Alchemy must generate code that works 
uniformly across all instances. 

The top-level view of how Alchemy generates code for a procedure is as follows. 

4.1 Outline 

• In Definition [5] below we present a construction that, based on predicate p, builds a non- 
deterministic procedure Ap. 

• The code generated by Alchemy, code{p), is a backtracking implementation of Ap. Computation 
paths that do not succeed are recognized as such and abandoned, and Ap is finite-branching, so 
code(p) will always terminate. 

• If there exists any instance /' such that (/,/') satisfies p under r\ then some branch of Ap is 
guaranteed to compute such some such instance. 

Coping with inconsistent predicates It is possible for the code for a predicate p to fail on a given 
database instance /, either because the predicate is internally inconsistent or because no update of / 
can implement p without violating the facts. Alchemy is guaranteed to detect such situations; we treat 
predicates as transactions that rollback if they cannot be executed without violating their bodies or a fact. 

4.2 A normal form for predicates 

The general form of an Alloy predicate that specifies an operation and that Alchemy treats is 

pred p{s,s' : State, c?i : Ai, . . . : An){Qx . P(a,x)} 

where 2 is a sequence of quantified atoms and P is a quantifier free formula of relational algebra. Before 
giving an imperative interpretation of a predicate it is convenient to massage it into a convenient form. 
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Skolemization By the classical technique of Skolemization any formula Qx . (3(a,^) can be converted 
into a universal formula which is satisfiable if and only if Qx . P(a,x) is satisfiable. We exploit this trick in 
Alchemy as follows. Given a predicate p we convert it to a predicate p'^ whose body is in universal form; 
this involves expanding the specification language to include the appropriate Skolem functions. Suppose 
we generate code for p'^ (over the expanded language). Then given an original instance / we may view 
it as an instance over the enlarged schema, and apply the generated code to obtain an instance We 
ultimately return the instance /' that is the reduct of to the original schema. So in what follows we 
restrict attention to predicates whose body is a universal formula. 

Incorporating the facts Intuitively the facts in a specification comprise a separate set of constraints 
on how a predicate may build new instances from old ones. But by the following simple trick we can 
avoid treating the facts separately. When compiling a predicate to code we take each fact, prime every 
occurrence of the State sig, and add the fact to the body of the predicate. The use of primed State 
names means that the fact acts as a post-condition on the predicate. (Strictly speaking this is only true 
under an assumption of "state-boundedness" on the form of the facts, defined in t4J. The specifics of this 
syntactic assumption are irrelevant to the current paper so we omit details.) This in turn guarantees that 
any post-instance defined by the predicate will satisfy the facts. 
The following is a convenient form for formulas. 

Definition 3 (Special formulas). A special formula is a formula in either of the two forms 



fork> 1, with each e, not containing U or and with converse applied only to variables and relation 
names. 

Lemma 4. Any quantifier-free formula can be transformed into an equivalent Boolean combination of 
special formulas. 

Proof. It is easy to see that every expression is equivalent to one in which the converse operator ~ applies 
only to relation names or variables. It is easy to see that every expression other than itself is equivalent 
to one in which the constant never appears. Because union distributes over the other connectives every 
expression is equivalent to one of the form U . . . Ue„ (« > 1) with each e,- being U-free. 

We may take any equation e = f and replace it with {e in /) A (/ in e). We do this as long as neither 
e nor / is the term 0. 

Now each basic formula is in one of the forms 

(JiU...UJ„,)in(/iU...U/„) or (Jj U . . . U not in (/i U . . . U/,,) 

with n,m>0, where the J, and the /, are U-free. We may transform the basic formulas above into the 
corresponding forms 

(t/iU...Ut/„)-(/iU...U/„) = 0, respectively, (^/i U . . . Ucf^) - (/i U . . . U/„) / (3) 
The first equation in|3]is equivalent, via distributivity of U over n, to the conjunction of the equations 



{ein.-.nek) = 



or 



(f'ln.-.ne^) /0 



J,--(/iU...u/„)=0 



In turn, each of these is equivalent to the special formula 



{di-fi)n...n{di 



fn) = 
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Similar reasoning shows that each dis-equation as in [3] is equivalent to a disjunction of special formulas 

(...((^/,--/l)-/2)-...-/„)/0 

□ 

4.3 Algorithms 

Bridging tiie declarative/imperative gap The main procedure Ap below is generated by an induction 
that walks the structure of the formula that is the body of p. There is a natural correspondence between the 
logical operators in the predicate and control-flow operators in the generated procedure. The disjunctive 
(logical V and 3) constructors in predicates naturally suggest imperative nondeterminism; this of course 
results in backtracking in generated code. Likewise, conjunctive (logical A and V) constructors lead 
naturally to sequencing. This is natural enough, but a difficulty arises due to the fact that the logical 
operators are commutative but command-sequencing certainly is not. Indeed, implementing one part of 
a predicate can undo the effect achieved by an earlier part. The solution is to iterate computation until 
a fixed-point is reached on the post-state. So we must be careful to ensure that such an iteration will 
always halt. 

Compiling special formulas to code Consider for example the body of the Drop predicate in Figure [T] 
There are certainly many ways to update the data to make this true; for example we could delete all the 
tuples in the roster table! This is not what the specifier had in mind. But even this silly example points 
out the need for a principled approach to update. We start with the following goal: we attempt to make a 
minimal set of updates (measured by the number of tuples inserted or deleted into tables) to the system 
to satisfy the predicate. 

The virtue of special formulas is that they facilitate identifying minimal updates to make a formula 
true. For example the formula a in s'.r, which, when a is an atom, is to say that a is in the relation s' .r is 
equivalent to the formula a — (s'.r) = 0. So suppose a — (s'.r) = is part of the body of a predicate. We 
evaluate the expression a — {s' .r) in the pre-state and the current post-state: if the value of this expression 
is indeed empty then there is nothing to do. If it is not empty then a is not in s' .r, and it is clear what 
action to take: add a to s'.r. 

More generally, when confronted with a special formula e = we may view any tuples in the current 
value of e as obstacles to the truth of the formula. Then the action suggested by the formula is clear: 
make whatever insertions or deletions we can to ensure the formula becomes true. (The presence of 
the difference operator means that making an expression empty may involve insertions.) The important 
thing to note is that, obviously, we may focus exclusively on tuples that are already in the value of e 
in attempting to make e = in the updated state. This is our strategy for doing minimal updates for a 
predicate. 

Inserting and deleting tuples We have seen that compiling a special formula amounts to orchestrating 
the insertion or deletion of individual tuples from the relations denoted by expressions. These expressions 
correspond to database views, and indeed the task of inserting or deleting a tuple from a view is an 
instance of the well-known view update problem |El[3l. Our code proceeds by a structural induction over 
the expression: see the procedures insertTuple and deleteTuple below. 
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Putting it all together After the preceding discussion the pseudocode for the Alchemy 's translation 
algorithm should be largely self-explanatory. For simplicity in notation we adopt the following 
conventions. There are global variables pre-state and post-state ranging over instances, and a global 
variable Updates which keeps a record of the insertions and deletions done as the algorithm progresses. 

We make use of the following function Eval(e : expression. : database instances) that returns the 
set of tuples denoted by expression e under the convention that immutable relation-name occurrences are 
interpreted in J and mutable relation-name occurrences are interpreted in f. The pseudocode given here 
for procedures Ap, Mp, insertTuple, and deleteTuple is directly based on the discussion in the previous 
paragraphs. 

Definition 5 (Algorithm A^). Let phea Alloy predicate of the form 

pred p{s,s' : State, ai : Ai,...,a„ :A„) . {ix . /\\/ Oij} 

i j 

where each cSij is a special formula. The procedure determined by p is as follows. Each of A^ and 
Mp reads the instance / globally and reads and writes /' and Updates globally. 

procedure Ap (/: database instance) { 
initialize poststate /' to be /; 
initialize Updates to be empty; 
repeat Mp{ai : Ai, . . . ,a„ : A„) 
until no change in Updates 

} 

procedure Mp{ai :Ai,...,a„ :A„) { 

for each binding b of values in / for the variables in a: 
let A( ^ij be the body of p instantiated by b: 
for each conjunct V ^ ^ij 

choose some Gtj and realize dij as follows: 
Case 1 : Oij is of the form (ei n . . . n e^t) = 
set e = (ei n . . . n e^) 
for each tuple t in Eval(e, /,/'): 
call deleteTuple {t,e, I, I'); 
Case 2: a,- y is of the form (ei n . . . n e^t) / 
set e = (ei n . . . n e^) 
choose some t of the same type as e 
call insertTuple( t, e. I, I') 
update Updates accordingly; 

} 

procedure insertTuple(/ : tuple, e\ expression) { 
match e : 

atom a:iia^t then FAIL else RETURN 

immutable relation r: lit then FAIL else RETURN 

mutable relation r: if / has been previously deleted from r then FAIL 

else add t to the table r 'mJ' 
eiUe2: choose some e,- ; insertTupIe(?,ej) 
ei ne2: insertTupIe(?,ei) ; insertTupIe(?,e2) 
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'-^ e: insertTuple( t,e) 

{ei ,62) '■ let f = {ti , t2) where f,- matches type of e,-; insertTuple(fi ,ei); insertTuple(f2 , ^2) 

ei —62- insertTuple(f,ei) ; deleteTuple(f,e2) 

ei .62'. let T be the common sig-type that joins ei and 62', 

if T is the type of ei then for some a in Eval(ei ,/,/'), insertTuple((a,f),e2) 
elseif T is the type of €2 then for some a in Eval(e2,^,^')' insertTuple((?,a),ei) 
else choose a : T ; set ti = {s\,a) and set t2 = {a,S2)', 
insertTuple(fi,ei) ; insertTuplefe , ^2) 

(^i)*: insertTuple(?,ei) 

procedure deleteTuple(f : tuple, e: expression) { 
match e: 

atom a:iia = t then FAIL else RETURN 

immutable relation r: if f G r then FAIL else RETURN 

mutable relation r: if t has been previously inserted into r then FAIL 

else delete t from the table r in /' 
ei Ue2- deleteTuple(f,ei) ; deleteTuple(f,e2) 
eirie2- choose some e,- ; deleteTuple(?,e,) 
e: deleteTuple( t^e) 

(^1 ,^2): let ? = (fi ,^2) where ti matches type of eu choose some e,-; deleteTuple(f; , e,) 
e\ — £2- choose: deleteTuple(f,ei) or insertTuple(?,e2) 
e\ .62: let T be the common sig-type that joins ei and €2', 

if T is the type of ei then for each a in Eval(ei, /,/'), deleteTuple((fl',f),g2) 

elseif T is the type of €2 then for each a in Eval(e2 JJ'), deleteTuple( {t,a),ei) 

else for each a : T such that for some si,S2, 

{si,a) = ti is in ei and {a,S2) = t2 is in €2 and t\.t2 = t; 
choose ei then deleteTuple(f,- , e,) 
(ei)*: for each {y\,y2)^ • • • , {yn,y) such that t = (x,y) and each pair is in ei 

choose some pair {yi,yi+y)\ deleteTuple((3;,-,3;,+i),ei) 



4.4 Proof of correctness 

Proof of Theorem|2] Theorem |2] follows from the following lemma about Kp. 

Lemma 6. Let p be a predicate; let Ap be the non-deterministic procedure constructed from p by 
Definition \5\ Then for every instance I and binding r\ for the parameters of p: 

1. Every computation of Ap terminates on I under r], and if Ap returns an instance I', we have 

2. If there is an instance /' such that {1,1') € [/jK^) ^^^'^ not fail. 

Proof of the lemma. For the first claim, first note that algorithm Bp proceeds by primitive recursion over 
the body of the predicates and algorithms insertTuple and deleteTuple proceed by primitive recursion 
over the body of expressions. So it suffices to argue that the iteration until fixed point in algorithm 
always terminates. But this follows from the fact that we never add or delete the same tuple from a given 
relation and the total size of the domain we work with never changes. It is easy to see that when Ap halts 
without failure it is the case that the body of the predicate has been satisfied. 
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To establish the second claim we start with a definition. Given instances / and /' let us say that 
instance J is an {I , I') -approximation if / — 7 C / — /' and J — I C I' — I. We abuse notation slightly here: 
these calculations are done on a per-relation basis. Intuitively J is an (/,/')-approximation if J can be 
obtained from / by making some of the inserts and deletes that transform / into Note that / is an 
(/,/')-approximation, as is Now the second claim follows from the fact that, for initial instance / 
and chosen /' with (/,/') G I/'K^)' whenever algorithm Mp is called (by A^) when the current value of 
the poststate is an (/,/') -approximation then there is a computation of Bp that (i) does not fail, and (ii) 
updates the poststate so that it still is an (7,/')-approximation. In particular Ap will never fail. □ 

Complexity There is nothing interesting that can be said about the run-time complexity of code{p) 
since it depends on the nature of the predicate p, and p can be an arbitrary predicate. On the other 
hand it is natural to ask about the complexity of code() itself. In other words, what is the running time 
of Alchemy 's code generation algorithm? Since co6e{p) comprises a backtracking wrapper around the 
algorithm Ap the question is essentially the same as asking: what is the complexity of building the text 
of algorithm Ap from the text of predicate pi It is easy to see that this is linear in p. Note in particular 
that the procedures insertTuple and deleteTuple do not depend on p at all. 

5 Related Work 

For an extensive discussion of previous research relevant to the Alchemy project itself we refer the reader 
to the related work section in f7 |. The relationship of the present paper to the previous work on Alchemy 
is as follows. In |7| we did not handle the relational difference operator, we did not treat Skolemization, 
and our correctness result was only for a subset of Alloy predicates (those admitting "homogeneous" 
implementations as defined there). But most importantly, the treatment of when relation names were 
evaluated in the pre-state and when in the post-state was ad-hoc: in the current paper this important 
semantic decision rests on the secure foundations of the work in [4]. This allows us to prove a true 
soundness and completeness theorem (Theorem |2]) for our code-generation algorithm. 
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